build(platform)!: adopt GroveDB 6.0 with automatic backward references and grovedb-bincode 2.1.0 - #4635

Issue being fixed or feature implemented

Platform pinned GroveDB at 6fc7e1e8 together with the QuantumExplorer rust-rocksdb fork, and rust-dashcore at a revision from before GroveDB's bincode moved to the published grovedb-bincode crate. This PR advances those dependencies and adapts Drive, the FFI and the wasm SDK to the GroveDB API changes, without changing how Platform decodes anything. The untrusted-decoding adoption in #4625 builds on top of it.

Companion changes: GroveDB #948, GroveDB #949 GroveDB #951 and GroveDB #953 (per-operation backward-reference declarations through the DontCheckForBackwardsReferences op twins) are merged on develop, which is pinned at the #953 merge commit 6816457d2b2df98653f286bf9a374f236a17748f; rust-dashcore #1005 is merged (dev e4208c90786a6854bd498315bcb571ef24182c15).

What was done?

• Advance GroveDB to develop f75fa362 (6.0.0 plus fix(dashmate): wrong envoy config path on windows #949 and feat(dashmate): verbose connect ENOENT /var/run/docker.sock error #951, about fifty commits since 6fc7e1e8, including the V1 proof hardening series) and rust-dashcore to dev e4208c90. Use rocksdb 0.25.0 from crates.io instead of the rust-rocksdb fork. Make the workspace bincode dependency an alias for the published grovedb-bincode 2.1.0 so GroveDB, rust-dashcore and Platform share one set of bincode traits; no Cargo patch is needed.
• Build RocksDB 11.8.1 for the prebuilt static library in the Docker image and in the librocksdb GitHub action, matching librocksdb-sys 0.19.0+11.8.1. RocksDB 11's C API dropped the in_range slice-transform callback, so bindgen against the 10.x headers no longer compiles the rocksdb crate.
• Advance GroveDB to develop 6816457d (the merge of [WIP] ci: testing local/s3 backend for cache #953), which builds on feat(dashmate): verbose connect ENOENT /var/run/docker.sock error #951's automatic backward-reference maintenance and replaces its batch-level Maintain/Skip policy with a declaration on every operation: the live InsertOptions, DeleteOptions and ClearOptions carry backwards_references: BackwardsReferences::{Check, DontCheck}, and every displacing batch op has a DontCheckForBackwardsReferences twin (DeleteDontCheckForBackwardsReferences, DeleteTreeDontCheckForBackwardsReferences, InsertOrReplaceDontCheckForBackwardsReferences, ReplaceDontCheckForBackwardsReferences, PatchDontCheckForBackwardsReferences) that declares the value it displaces takes no part in backward references. GroveDB reads the displaced value for the write anyway, so the declaration is checked for free: a twin over a value that turns out to participate is refused before anything commits, and only routes that read nothing (flat drop, raw clear) trust it. Drive stores no backward-reference participants, so it makes the declaration where each op is built: every delete, delete-tree, insert-or-replace, replace and patch op Drive constructs is built as its DontCheckForBackwardsReferences twin at the construction site (QualifiedGroveDbOp::delete_op(..).dont_check_for_backwards_references() and so on, 58 sites), the delete ops GroveDB builds on Drive's behalf (batch_delete, batch_move, batch_remove_raw, the path-query variants and the delete-up-tree chain) carry DontCheck from Drive's DeleteOptions and DeleteUpTreeOptions, the estimated delete builders receive the same declaration, and the live delete and clear options say DontCheck. The write ops are declared as well as the deletes because the estimator charges the displaced-participant fan-out per op declared Check; a checked replace would raise the estimated fee of every balance and pool update. Drive's batch-inspection code (batch_remove_raw, update_keywords, the batch Display) matches both the checked op and its twin. That keeps GroveDB V4's single prepared write path with feat(dashmate): verbose connect ENOENT /var/run/docker.sock error #951's read savings, removes the participant scans that had raised PV14 delete, transfer and purchase fees under the old Maintain policy, and needs no per-layer estimator declaration (the 165 may_contain_backward_references: false layer fields are gone with the field). When a document type starts storing participants, its ops are built as checked ops where they are created. GroveDB fix(dashmate): wrong envoy config path on windows #949 changes only V4 recursive subtree discovery over non-Merk descendants and needs no Drive change.
• Adapt to the other GroveDB API changes: element verification aligned with the prover's right-to-left traversal (GroveDB now checks it strictly), and the new backward-reference element variants rendered by the FFI and wasm SDK path-element queries.
• Verify a paged document query's cursor document in the page's walk direction. The prover merges the one-key cursor lookup into the page proof in the page's orderBy direction, and GroveDB fix(scripts): update configure_test_network for hpmn #863 now rejects a layer proof read in the other op family, which failed every proved descending page with a cursor. When a $id-ordered page merges its cursor lookup onto the primary-key layer itself (also for history-keeping types, whose cursor sits one level below), the prover now keeps the requested direction and reserves the extra limit slot only when the page's items do not already cover the cursor, since GroveDB 6 also rejects a layer returning more rows than the verifier's limit; round-trip tests page by $id in both directions with inclusive and exclusive cursors. The drive-abci contestant-votes test helper now verifies with the requested order and cursor, as the SDK's proof verifier does, and the proved test pages with cursors and limits in both directions.

How Has This Been Tested?

Local macOS: cargo fmt --all --check; cargo clippy --workspace --all-targets --all-features --locked -- --no-deps -D warnings; cargo nextest run -p drive --all-features (3,755 passed); cargo nextest run -p drive-abci --all-features (3,114 passed). Against the previous revision of this PR, every PV14 fee baseline holds except DPNS domain create and document replace, which come in 4,000 and 4,900 credits lower because GroveDB V4 writes through the Merk node it retains from reading the old value; those two are re-pinned, and both now have a _protocol_version_13 twin pinning the version 13 fee at its pre-change value (document replace already had one; DPNS domain create gets one at 6,010,380), alongside the unchanged PV11 twins. The earlier round on GroveDB 985ece65 also ran the CI nextest package set (14,855 passed) and built the Docker deps-rocksdb stage with RocksDB 11.8.1. No device or browser execution and no live network upgrade were exercised.

Breaking Changes

Rust consumers that serialize Platform or Core types must use the published grovedb-bincode 2.1.0 crate, since bincode trait identities now come from it. Existing bincode encodings and the C ABI are unchanged. PV14 processing fees for DPNS domain create and document replace drop by 4,000 and 4,900 credits (GroveDB V4 reuses the Merk node it read for the old value); every other baseline is unchanged and PV13 (GroveDB V3) is untouched.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone